Skip to content

Promote develop to main: a game on the retired render key is adopted, not refused - #668

Merged
jonit-dev merged 2 commits into
mainfrom
develop
Nov 12, 2026
Merged

jonit-dev merged 2 commits into
mainfrom
develop

Conversation

@jonit-dev

Copy link
Copy Markdown
Contributor

Promotes develop onto main so 0.3.13 can publish.

Why this promotion exists now: the previous merge (PR #666, 0acb5adc3) reached main green, but npm release refused to publish:

TN_RELEASE_UPGRADE_RED: a game on the previous latest does not upgrade onto this candidate. Nothing was published.
  FAIL  pnpm:gameplay  (starter)
  TN_PLAYTEST_BRIDGE_MISSING ... TN_GAME_RENDER_KEY_RENAMED

The release's upgrade proof scaffolds a game from registry latest and plays it on the candidate. [email protected] (published) generates render: config.renderer, and 0.3.13 made that key throw, so every existing game died at boot.

What changed on develop:

  • 550a2ae8e render is adopted onto renderer for one release (its values win, as they always did) and the same TN_GAME_RENDER_KEY_RENAMED guidance is reported instead of thrown; a non-object render still fails closed (TN_GAME_RENDER_KEY_INVALID). IGameConfig.render is @deprecated, so a 0.3.12 game typechecks and boots. The hard throw becomes a 0.4.0 break; the PRD risk row records the amendment.
  • 99b47c003 a worker error now carries filename:lineno:colno, so the intermittent worker deaths that cost two boards report their own line.

Verified:

  • A game scaffolded by the published create-threenative 0.2.17, installed against this tree's packed core: pnpm typecheck ✅, pnpm build:web ✅, and it now boots past the rename — the only remaining failure is a rig-local core/runtime-native version skew (0.3.13 beside registry 0.3.12) that the real cohort does not have.
  • packages/core suite: 337 files, 4779 tests pass. pnpm quality, pnpm typecheck, scaffold:pin --check clean.

This PR carries no PRD; it is the promotion gate.

0.3.13 folds the portable renderer half into `renderer` and made `render`
throw `TN_GAME_RENDER_KEY_RENAMED`. Every game on the published latest still
passes `render: config.renderer` — create-threenative 0.2.17 emits it — so the
release's own upgrade proof refused to publish 0.3.13:
`TN_RELEASE_UPGRADE_RED: a game on the previous latest does not upgrade onto
this candidate. Nothing was published.`

The key is now adopted for one release: its values are forwarded onto
`renderer` (`render` wins, the merge the rename always described), the same
`TN_GAME_RENDER_KEY_RENAMED` guidance is reported instead of thrown, and a
`render` that is not an object still fails closed as
`TN_GAME_RENDER_KEY_INVALID`. `IGameConfig.render` is declared `@deprecated`,
so a 0.3.12 game typechecks and boots unchanged; the hard throw is a 0.4.0
break.

Verified on a game scaffolded by the *published* create-threenative 0.2.17
against this tree's packed core: `pnpm typecheck` and `pnpm build:web` pass,
and the page boots past the rename — it now fails only on a rig-local
core/runtime-native version skew (0.3.13 beside registry 0.3.12), which the
real cohort does not have. Units: 337 files / 4779 tests, `pnpm quality`,
`pnpm typecheck`.
`onWorkerError` reported only `event.message`, so a worker that died during
boot reached the page — and the playtest bridge, and the release lane — as a
stack-less "Offset is outside the bounds of the DataView". The ErrorEvent
carries `filename`, `lineno` and `colno`; they now ride in the message, so
the next intermittent worker death names its own line.
@jonit-dev
jonit-dev merged commit f5d255d into main Nov 12, 2026
121 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant